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RFC 9146 
Connection Identifier for DTLS 1.2 


Abstract 


This document specifies the Connection ID (CID) construct for the Datagram Transport Layer 
Security (DTLS) protocol version 1.2. 


A CID is an identifier carried in the record layer header that gives the recipient additional 
information for selecting the appropriate security association. In "classical" DTLS, selecting a 
security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If 
the source IP address and/or source port changes during the lifetime of an ongoing DTLS session, 
then the receiver will be unable to locate the correct security context. 


The new ciphertext record format with the CID also provides content type encryption and record 
layer padding. 


This document updates RFC 6347. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 


on it may be obtained at https://www.rfc-editor.org/info/rfc9146. 


Copyright Notice 


Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights 
reserved. 
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This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. Code Components extracted from this document must include 
Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Revised BSD License. 


This document may contain material from IETF Documents or IETF Contributions published or 
made publicly available before November 10, 2008. The person(s) controlling the copyright in 
some of this material may not have granted the IETF Trust the right to allow modifications of 
such material outside the IETF Standards Process. Without obtaining an adequate license from 
the person(s) controlling the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may not be created outside the 
IETF Standards Process, except to format it for publication as an RFC or to translate it into 
languages other than English. 
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1. Introduction 


The Datagram Transport Layer Security (DTLS) protocol [RFC6347] was designed for securing 
data sent over datagram transports (e.g., UDP). DTLS, like TLS, starts with a handshake, which can 
be computationally demanding (particularly when public key cryptography is used). After a 
successful handshake, symmetric key cryptography is used to apply data origin authentication, 
integrity, and confidentiality protection. This two-step approach allows endpoints to amortize the 
cost of the initial handshake across subsequent application data protection. Ideally, the second 
phase where application data is protected lasts over a long period of time, since the established 
keys will only need to be updated once the key lifetime expires. 


In DTLS as specified in RFC 6347, the IP address and port of the peer are used to identify the DTLS 
association. Unfortunately, in some cases, such as NAT rebinding, these values are insufficient. 
This is a particular issue in the Internet of Things when devices enter extended sleep periods to 
increase their battery lifetime. The NAT rebinding leads to connection failure, with the resulting 
cost of a new handshake. 


This document defines an extension to DTLS 1.2 to add a Connection ID (CID) to the DTLS record 
layer. The presence of the CID is negotiated via a DTLS extension. 


Adding a CID to the ciphertext record format presents an opportunity to make other changes to 
the record format. In keeping with the best practices established by TLS 1.3, the type of the record 
is encrypted, and a mechanism is provided for adding padding to obfuscate the plaintext length. 


2. Conventions and Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


This document assumes familiarity with DTLS 1.2 [RFC6347]. The presentation language used in 
this document is described in Section 3 of [RFC8446]. 
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3. The "connection_id" Extension 


This document defines the "connection_id" extension, which is used in ClientHello and 
ServerHello messages. 


The extension type is specified as follows. 


enum { 
connection_id(54), (65535) 
} ExtensionType; 


The extension_data field of this extension, when included in the ClientHello, MUST contain the 
ConnectionId structure. This structure contains the CID value the client wishes the server to use 
when sending messages to the client. A zero-length CID value indicates that the client is prepared 
to send using a CID but does not wish the server to use one when sending. 


struct { 
opaque cid<@. .2%8-1>; 
} ConnectionId; 


A server willing to use CIDs will respond with a "connection_id" extension in the ServerHello, 
containing the CID it wishes the client to use when sending messages towards it. A zero-length 
value indicates that the server will send using the client's CID but does not wish the client to 
include a CID when sending. 


Because each party sends the value in the "connection_id" extension it wants to receive as a CID 
in encrypted records, it is possible for an endpoint to use a deployment-specific constant length 
for such connection identifiers. This can in turn ease parsing and connection lookup -- for 
example, by having the length in question be a compile-time constant. Such implementations 
MUST still be able to send CIDs of different lengths to other parties. Since the CID length 
information is not included in the record itself, implementations that want to use variable-length 
CIDs are responsible for constructing the CID in sucha way that its length can be determined on 
reception. 


In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session only. There is no dedicated 
"CID update" message that allows new CIDs to be established mid-session, because DTLS 1.2 in 
general does not allow TLS 1.3-style post-handshake messages that do not themselves begin other 
handshakes. When a DTLS session is resumed or renegotiated, the "connection_id" extension is 
negotiated afresh. 


If DTLS peers have not negotiated the use of CIDs, or a zero-length CID has been advertised fora 
given direction, then the record format and content type defined in RFC 6347 MUST be used to 
send in the indicated direction(s). 
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If DTLS peers have negotiated the use of a non-zero-length CID for a given direction, then once 
encryption is enabled, they MUST send with the record format defined in Figure 3 (see Section 4) 
with the new Message Authentication Code (MAC) computation defined in Section 5 and the 
content type tls12_cid. Plaintext payloads never use the new record format or the CID content 


type. 


When receiving, if the tls12_cid content type is set, then the CID is used to look up the connection 
and the security association. If the tls12_cid content type is not set, then the connection and the 
security association are looked up by the 5-tuple and a check MUST be made to determine 
whether a non-zero-length CID is expected. If a non-zero-length CID is expected for the retrieved 
association, then the datagram MUST be treated as invalid, as described in Section 4.1.2.1 of 
[RFC6347]. 


When receiving a datagram with the tls12_cid content type, the new MAC computation defined in 
Section 5 MUST be used. When receiving a datagram with the record format defined in RFC 6347, 
the MAC calculation defined in Section 4.1.2 of [RFC6347] MUST be used. 


4. Record Layer Extensions 


This specification defines the CID-enhanced record layer format for DTLS 1.2, and [DTLS13] 
specifies how to carry the CID in DTLS 1.3. 


To allow a receiver to determine whether a record has a CID or not, connections that have 
negotiated this extension use a distinguished record type tls12_cid(25). The use of this content 
type has the following three implications: 


e The CID field is present and contains one or more bytes. 
e The MAC calculation follows the process described in Section 5. 
° The real content type is inside the encryption envelope, as described below. 


Plaintext records are not impacted by this extension. Hence, the format of the DTLSPlaintext 
structure is left unchanged, as shown in Figure 1. 


struct { 

ContentType type; 

ProtocolVersion version; 

uint16 epoch; 

uint48 sequence_number; 

uint16 length; 

opaque fragment[DTLSPlaintext.length] ; 
} DTLSPlaintext; 


Figure 1: DTLS 1.2 Plaintext Record Payload 


When CIDs are being used, the content to be sent is first wrapped along with its content type and 
optional padding into a DTLSInnerPlaintext structure. This newly introduced structure is shown 
in Figure 2. 
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struct { 
opaque content[length]; 
ContentType real_type; 
uint8 zeros[length_of_padding] ; 
} DTLSInnerPlaintext; 


Figure 2: New DTLSInnerPlaintext Payload Structure 


content: Corresponds to the fragment of a given length. 
real_type: The content type describing the cleartext payload. 


zeros: An arbitrary-length run of zero-valued bytes may appear in the cleartext after the type 
field. This provides an opportunity for senders to pad any DTLS record by a chosen amount as 
long as the total stays within record size limits. See Section 5.4 of [RFC8446] for more details. 
(Note that the term TLSInnerPlaintext in RFC 8446 refers to DTLSInnerPlaintext in this 
specification.) 


The DTLSInnerPlaintext byte sequence is then encrypted. To create the DTLSCiphertext structure 
shown in Figure 3, the CID is added. 


struct { 
ContentType outer_type = tls12_cid; 
ProtocolVersion version; 
uint16 epoch; 
uint48 sequence_number; 
opaque cid[cid_length]; // New field 
uint16 length; 
opaque enc_content[DTLSCiphertext.length] ; 
} DTLSCiphertext; 


Figure 3: DTLS 1.2 CID-Enhanced Ciphertext Record 


outer_type: The outer content type of a DTLSCiphertext record carrying a CID is always set to 
tls12_cid(25). The real content type of the record is found in DTLSInnerPlaintext.real_type 
after decryption. 


cid: The CID value, cid_length bytes long, as agreed at the time the extension has been 
negotiated. Recall that each peer chooses the CID value it will receive and use to identify the 
connection, so an implementation can choose to always receive CIDs of a fixed length. If, 
however, an implementation chooses to receive CIDs of different lengths, the assigned CID 
values must be self-delineating, since there is no other mechanism available to determine 
what connection (and thus, what CID length) is in use. 


enc_content: The encrypted form of the serialized DTLSInnerPlaintext structure. 


All other fields are as defined in RFC 6347. 
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5. Record Payload Protection 


Several types of ciphers have been defined for use with TLS and DTLS, and the MAC calculations 
for those ciphers differ slightly. 


This specification modifies the MAC calculation as defined in [RFC6347] and [RFC7366], as well as 
the definition of the additional data used with Authenticated Encryption with Associated Data 
(AEAD) ciphers provided in [RFC6347], for records with content type tls12_cid. The modified 
algorithm MUST NOT be applied to records that do not carry a CID, i.e., records with content type 
other than tls12_cid. 


The following fields are defined in this document; all other fields are as defined in the cited 
documents. 


cid: Value of the negotiated CID (variable length). 
cid_length: The length (in bytes) of the negotiated CID (one-byte integer). 


length_of_DTLSInnerPlaintext: The length (in bytes) of the serialized DTLSInnerPlaintext (two- 
byte integer). The length MUST NOT exceed 2414. 


seq_num_placeholder: 8 bytes of Oxff. 


Note that "+" denotes concatenation. 


5.1. Block Ciphers 


The following MAC algorithm applies to block ciphers that do not use the Encrypt-then-MAC 
processing described in [RFC7366]. 


MAC(MAC_write_key, 
seq_num_placeholder + 
tls12_cid + 
cid_length + 
lish 2acadet 
DTLSCiphertext.version + 
epoch + 
sequence_number + 
cid + 
length_of_DTLSInnerPlaintext + 
DTLSInnerPlaintext.content + 
DTLSInnerPlaintext.real_type + 
DTLSInnerPlaintext.zeros 


es 


The rationale behind this construction is to separate the MAC input for DTLS without the 
connection ID from the MAC input with the connection ID. The former always consists of a 
sequence number followed by some content type other than tls12_cid; the latter always consists 
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of the seq_num_placeholder followed by tls12_cid. Although 264-1 is potentially a valid sequence 
number, tls12_cid will never be a valid content type when the connection ID is not in use. In 
addition, the epoch and sequence_number are now fed into the MAC in the same order as they 
appear on the wire. 


5.2. Block Ciphers with Encrypt-then-MAC Processing 


The following MAC algorithm applies to block ciphers that use the Encrypt-then-MAC processing 
described in [RFC7366]. 


MAC(MAC_write_key, 
seq_num_placeholder + 
tlsi2 acidit 
cid_length + 
tls12_cid + 
DTLSCiphertext.version + 
epoch + 
sequence_number + 
cidit 
DTLSCiphertext.length + 
IV + 
ENC(content + padding + padding_length) 


J 


5.3. AEAD Ciphers 


For ciphers utilizing AEAD, the following modification is made to the additional data calculation. 


additional_data = seq_num_placeholder + 
tli Sii2ecadie 
cid_length + 
tls12_cid + 
DTLSCiphertext.version + 
epoch + 
sequence_number + 
cid + 
length_of_DTLSInnerPlaintext; 


6. Peer Address Update 


When a record with a CID is received that has a source address different from the one currently 
associated with the DTLS connection, the receiver MUST NOT replace the address it uses for 
sending records to its peer with the source address specified in the received datagram, unless the 
following three conditions are met: 


e The received datagram has been cryptographically verified using the DTLS record layer 
processing procedures. 
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e The received datagram is "newer" (in terms of both epoch and sequence number) than the 
newest datagram received. Reordered datagrams that are sent prior to a change in a peer 
address might otherwise cause a valid address change to be reverted. This also limits the 
ability of an attacker to use replayed datagrams to force a spurious address change, which 
could result in denial of service. An attacker might be able to succeed in changing a peer 
address if they are able to rewrite source addresses and if replayed packets are able to arrive 
before any original. 


e There is a strategy for ensuring that the new peer address is able to receive and process DTLS 
records. No strategy is mandated by this specification, but see note (*) below. 


The conditions above are necessary to protect against attacks that use datagrams with spoofed 
addresses or replayed datagrams to trigger attacks. Note that there is no requirement for the use 
of the anti-replay window mechanism defined in Section 4.1.2.6 of [RFC6347]. Both solutions, the 
"anti-replay window’ or "newer" algorithm, will prevent address updates from replay attacks 
while the latter will only apply to peer address updates and the former applies to any application 
layer traffic. 


Note that datagrams that pass the DTLS cryptographic verification procedures but do not trigger 
a change of peer address are still valid DTLS records and are still to be passed to the application. 


(*) Note: Application protocols that implement protection against spoofed addresses depend 
on being aware of changes in peer addresses so that they can engage the necessary 
mechanisms. When delivered such an event, an address validation mechanism specific to the 
application layer can be triggered -- for example, one that is based on successful exchange of a 
minimal amount of ping-pong traffic with the peer. Alternatively, a DTLS-specific mechanism 
may be used, as described in [DTLS-RRC]. 


DTLS implementations MUST silently discard records with bad MACs or that are otherwise invalid. 


7. Example 


Figure 4 shows an example exchange where a CID is used unidirectionally from the client to the 
server. To indicate that a zero-length CID is present in the "connection_id" extension, we use the 
notation 'connection_id=empty’. 
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Client Server 


ClientHello o ===- > 
(connection_id=empty) 


<-------- HelloVerifyRequest 
(cookie) 
CiirentHellos Sess) soso > 
(connection_id=empty) 
(cookie) 
ServerHello 
(connection_id=100) 
Certificate 
ServerKeyExchange 
CertificateRequest 
Soo ServerHelloDone 
Certificate 
ClientKeyExchange 
CertificateVerify 
[ ChangeCipherSpec] 
Fainashedy 7 a eae > 
<CID=100> 
[ChangeCipherSpec] 
Ea tl Finished 
Application Data =—=—— = 
<CID=100> 
oa Application Data 
Legend: 
<...> indicates that a connection ID is used in the record layer 
(...) indicates an extension 
[...] indicates a payload other than a handshake message 


Figure 4: Example DTLS 1.2 Exchange with CID 


Note: In the example exchange, the CID is included in the record layer once encryption is 
enabled. In DTLS 1.2, only one handshake message is encrypted, namely the Finished message. 
Since the example shows howto use the CID for payloads sent from the client to the server, 
only the record layer payloads containing the Finished message or application data includea 
CID. 
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8. Privacy Considerations 


The CID replaces the previously used 5-tuple and, as such, introduces an identifier that remains 
persistent during the lifetime of a DTLS connection. Every identifier introduces the risk of 
linkability, as explained in [RFC6973]. 


An on-path adversary observing the DTLS protocol exchanges between the DTLS client and the 
DTLS server is able to link the observed payloads to all subsequent payloads carrying the same ID 
pair (for bidirectional communication). Without multihoming or mobility, the use of the CID 
exposes the same information as the 5-tuple. 


With multihoming, a passive attacker is able to correlate the communication interaction over the 
two paths. The lack of a CID update mechanism in DTLS 1.2 makes this extension unsuitable for 
mobility scenarios where correlation must be considered. Deployments that use DTLS in 
multihoming environments and are concerned about these aspects SHOULD refuse to use CIDs in 
DTLS 1.2 and switch to DTLS 1.3 where a CID update mechanism is provided and sequence number 
encryption is available. 


This specification introduces record padding for the CID-enhanced record layer, which is a 
privacy feature not available with the original DTLS 1.2 specification. Padding allows the size of 
the ciphertext to be inflated, making traffic analysis more difficult. More details about record 
padding can be found in Section 5.4 and Appendix E.3 of [RFC8446]. 


Finally, endpoints can use the CID to attach arbitrary per-connection metadata to each record 
they receive on a given connection. This may be used as a mechanism to communicate per- 
connection information to on-path observers. There is no straightforward way to address this 
concern with CIDs that contain arbitrary values. Implementations concerned about this aspect 
SHOULD refuse to use CIDs. 


9. Security Considerations 


An on-path adversary can create reflection attacks against third parties because a DTLS peer has 
no means to distinguish a genuine address update event (for example, due to a NAT rebinding) 
from one that is malicious. This attack is of particular concern when the request is small and the 
response large. See Section 6 for more on address updates. 


Additionally, an attacker able to observe the data traffic exchanged between two DTLS peers is 
able to replay datagrams with modified IP addresses / port numbers. 


The topic of peer address updates is discussed in Section 6. 


10. IANA Considerations 


This document implements three IANA updates. 
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10.1. Extra Column Added to the TLS ExtensionType Values Registry 


IANA has added an extra column named "DTLS-Only" to the "TLS ExtensionType Values" registry 
to indicate whether an extension is only applicable to DTLS and to include this document as an 
additional reference for the registry. 


10.2. New Entry in the TLS ExtensionType Values Registry 


IANA has allocated an entry in the existing "TLS ExtensionType Values" registry for 
connection_id(54), as described in the table below. Although the value 53 had been allocated by 
early allocation for a previous version of this document, it is incompatible with this document. 
Therefore, the early allocation has been deprecated in favor of this assignment. 


Value Extension Name TLS1.3  DTLS-Only Recommended Reference 


54 connection_id CH, SH Y N RFC 9146 
Table 1 
Anew column, "DTLS-Only", has been added to the registry. The valid entries are "Y" if the 


extension is only applicable to DTLS, "N" otherwise. All the pre-existing entries are given the value 
"N". 


Note: The value "N" in the "Recommended" column is set because this extension is intended 
only for specific use cases. This document describes the behavior of this extension for DTLS 1.2 
only; it is not applicable to TLS, and its usage for DTLS 1.3 is described in [DTLS13]. 


10.3. New Entry in the TLS ContentType Registry 


IANA has allocated tls12_cid(25) in the "TLS ContentType" registry. The tls12_cid content type is 
only applicable to DTLS 1.2. 
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